Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-116.txt

Text File | 1994-12-08 | 43.0 KB | 1,098 lines | [TEXT/R*ch]

C.S.M.P. Digest             Wed, 17 Jun 92       Volume 1 : Issue 116

Today's Topics:

    prefs
    Recording with the Sound Manager
    Apple UI Police & Pointer Movement
    How to get 360 dpi on stylewriter.


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Jim Ryan)
Subject: prefs
Organization: Adobe Systems Incorporated
Date: Wed, 13 May 1992 17:16:17 GMT

Is it recommended to write out prefs to the data fork, or
into/as a resourse?  Which is easier or more reliable?
Any prefs experts out there?

All I have are a few radio buttons, check boxes, and two Points
that I would like to save into a prefs file.  Should I go the File
Manager or Resourse Manager route?

Thanks,
jr


+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 14 May 92 01:56:34 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Jim Ryan) writes:
>Is it recommended to write out prefs to the data fork, or
>into/as a resourse?  Which is easier or more reliable?
>Any prefs experts out there?

>All I have are a few radio buttons, check boxes, and two Points
>that I would like to save into a prefs file.  Should I go the File
>Manager or Resourse Manager route?


If its small use the resource. If its large use the filemanager.
You could actually store the values of your controls in a cntl template
in the resource fork.



But DON'T CREATE A PREF FILE UNLESS THE USER CHANGES THE DEFAULT VAULES.

Matt






- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Ed Watkeys)
Date: 14 May 92 03:33:51 GMT
Organization: Distant Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jim Ryan) writes:
> Is it recommended to write out prefs to the data fork, or
> into/as a resourse?  Which is easier or more reliable?
> Any prefs experts out there?
>
> All I have are a few radio buttons, check boxes, and two Points
> that I would like to save into a prefs file.  Should I go the File
> Manager or Resourse Manager route?
>
> Thanks,
> jr

I have another question about preferences: should the menu item be in the
File or Edit menu? I'd like to keep the UI on my current project as consistent
as possible.

Ed

- --
Ed Watkeys (Drexel U. Comp Sci)  "Moral judgement and condemnation is
[e-mail]              the favorite form of revenge for the
[e-mail]      spiritually limited on those who are
ls.com!phlpa!caligula!edw         less so...." -- Friedrich Nietzsche

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 14 May 1992 15:18:51 GMT

[e-mail] (Ed Watkeys) writes:
>
>I have another question about preferences: should the menu item be in the
>File or Edit menu? I'd like to keep the UI on my current project as consistent
>as possible.

There was a discussion on AppleLink about this a few months ago.  I
don't think it went anywhere.  Until Apple lays down the law, there
aren't any hard'n'fast rules about the "Preferences..." menu item.
I prefer the second-to-last item in File, because that's where I see it
most often;  some people prefer the last item in Edit, because it's
something you're editing.  AppleLink makes it a hierarchical menu at the
end of the "Mail" menu--go figure.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Civil Rights:  1964 - 1992.  R.I.P.

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 14 May 92 15:09:58 GMT
Organization: The World Public Access UNIX, Brookline, MA

<< Is it recommended to write out prefs to the data fork, or
into/as a resourse?  Which is easier or more reliable?
Any prefs experts out there? >>

Data fork is easier. It will work fine as long as you have a structure set
up to hold your prefs.

- --
- -- joe zobkiw                             Internet: [e-mail]
- --                                             AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm          CI$: 70712,515
- -- communications.networks.cool tunes...

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hall)
Date: Fri, 15 May 92 07:38:59 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (Joe Zobkiw) writes:

><< Is it recommended to write out prefs to the data fork, or
>into/as a resourse?  Which is easier or more reliable?
>Any prefs experts out there? >>

>Data fork is easier. It will work fine as long as you have a structure set
>up to hold your prefs.

And using a stream class makes it even easier!  Check out the class in
MacApp 3.0, or the article in the last issue of SPLASH.


- --

 \ | /   | Brian Hall                 [e-mail]
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | People don't kill people, toasters kill people.

+++++++++++++++++++++++++++

From: [e-mail] (Jim Ryan)
Date: 14 May 92 17:57:16 GMT

Message-ID: <[e-mail]>
Sender: [e-mail] (USENET NEWS)
Organization: Adobe Systems Incorporated
Date: Wed, 13 May 1992 17:16:17 GMT

Is it recommended to write out prefs to the data fork, or
into/as a resourse?  Which is easier or more reliable?
Any prefs experts out there?

All I have are a few radio buttons, check boxes, and two Points
that I would like to save into a prefs file.  Should I go the File
Manager or Resourse Manager route?

Thanks,
jr

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Organization: Helsinki University of Technology, Finland
Date: Fri, 15 May 1992 09:06:24 GMT

In article <[e-mail]> [e-mail] (Joe Zobkiw) writes:
><< Is it recommended to write out prefs to the data fork, or
>into/as a resourse?  Which is easier or more reliable?
>Any prefs experts out there? >>
>
>Data fork is easier. It will work fine as long as you have a structure set
>up to hold your prefs.

I found version management of preferences files to be a real problem. Adding
new variables made the old preferences files incompatible with the new
software and I had to reset all my settings every time.

To get rid of this problem, I wrote a CTagHandle class for TCL. It allows
you to sequentially write data into a handle. Each data item is associated
with a 4 byte tag string (an OSType) a 2 byte length (configurable to 4 bytes
with a single #define) and some amount of data. I guess the structure is
quite similar to the clipboard format.

The idea is that when you read the preferences, you first se all the
varibles to some hard-coded defaults you then go through all the tags
with a switch statement and change your variables one by one. If there
are old and obsolete tags or new and unknown tags, you just ignore them.

Instead of having hard-coded defaults you can of course read a CTagHandle
with all your preferences set before you read the user preferences.

When you write out preferences, you just create a tagged item for every
parameter you have.

The routines are very simple and they are much easier to manage than a
single preferences structure. This is especially true if you have many
software components that need separate sets of preferences. The components
just add their tags to the preferences and every component gets a chance
to read all the tags.

I use a resource for storing PICT document settings this way. Every
document I save ends up having this resource. If the PICT comes from
another application, I end up using default values.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------

From: [e-mail] (John Tseng)
Subject: Recording with the Sound Manager
Date: 14 May 92 03:52:02 GMT
Organization: U.C. Berkeley Open Computing Facility

How do you record a 5 kHz sound with the Sound Manager?

Using the techniques in IM VI I can get a 22 kHz sound, or a compressed
sound, but how do you do 5 kHz?

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 15 May 92 21:09:24 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (John Tseng) writes:
>How do you record a 5 kHz sound with the Sound Manager?
>
>Using the techniques in IM VI I can get a 22 kHz sound, or a compressed
>sound, but how do you do 5 kHz?

You could use your own interrupt routine to downsample from 22kHz to 5kHz.
It has to be in assembly language, but it's not hard to do if you know
some assembly.

Of course you should check to see if the sampling device already supports
5kHz and use that if it knows how to do it.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------

From: [e-mail] (Rogers)
Subject: Apple UI Police & Pointer Movement
Date: 30 Apr 92 16:58:59 GMT
Organization: The MITRE Corporation, Bedford, MA

[e-mail] (Andrew Loewenstern) writes:
>
> [e-mail] (Matt Mora) writes:
>
>> I thought I read somewhere that AUIP frowned upon changing the cursor
>> location on the user.
>
> I don't remember seeing this explicitly stated somewhere, but it would
> make sense for this to be a nono.  Many people would get confused if
> the cursor started moving around on them.

Contrary to popular belief, there are some limited circumstances under
which application control of cursor movement is useful. As an example,
I am writing an application (non-Mac based, & using a trackball rather
than a mouse as the pointer-input device) that displays two primary
windows: 1) a large display of a map & associated geographical data, and
2) a smaller window containing a menu of buttons. One of the buttons in
the menu allows the user to select a new geographical position about
which to center the map window. Following the selection of this button,
the app then waits for the user to select, via the trackball, a point
on the map to be used as the new map-window center (I recognize that
this is not a modeless interaction & use a cursor-change to reflect
the mode-change). Rather than force the user to roll the trackball
all the way across the screen from the button he's just pressed to
the map window, my app immediately relocates the cursor to the map
center, thus minimizing the distance the user has to roll the trackball
to reach the new center point. Once the new center point has been
selected, the app relocates the cursor back to its previous position
in the menu, over the button that was just selected.

While this cursor relocation may take "a bit of getting used to," it
makes the selection of new map centers (a frequent operation) go much
more smoothly.

I have to admit, however, that if I was using a better (and more literal)
input device, such as a Mac mouse, or if my display was smaller, I probably
would have chosen NOT to relocate the cursor.

Just as hardware changes on the Mac (the availability of large displays)
made necessary UI elements that hadn't been common before (tear-off menus),
so do other changes also affect UI design choices.

Good UI practices are NEVER absolute, but must always be adaptable to the
application (& user-audience) at hand.

- --- Jeff Rogers
    [e-mail]
    The MITRE Corp.
    Bedford MA USA

+++++++++++++++++++++++++++

From: [e-mail] (Edward V. Wright)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Fri, 1 May 1992 16:11:01 GMT

In <[e-mail]> [e-mail] (Rogers) writes:

>Contrary to popular belief, there are some limited circumstances under
>which application control of cursor movement is useful.... One of the
>buttons in the menu allows the user to select a new geographical
>position about which to center the map window. Following the selection
>of this button, the app then waits for the user to select, via the
>trackball, a point on the map to be used as the new map-window center.
>Rather than force the user to roll the trackball
>all the way across the screen from the button he's just pressed to
>the map window, my app immediately relocates the cursor to the map
>center,

So, rather than use scroll bars or a grabber "hand," you chose a
nonstandard method of scrolling the map.  Then you grab the cursor
out of the user's hand, forcing him to hunt for it somewhere on the
map before he can continue.  Still sounds pretty user-nasty to me.

>While this cursor relocation may take "a bit of getting used to," it
>makes the selection of new map centers (a frequent operation) go much
>more smoothly.

You can make arguments like that about a lot of operations.  The problem
is, yours may not be the only program the user uses.  You, as a programmer,
may be focused on your product, and see it only as "a bit of getting
used to."  But if the user has a dozen programs, and he has to "get used
to" the idiosynchronsies of each one (learn them, remember them, and keep
them straight), he sees it as a pain in the neck.  Worse, many programmers
never bother testing their innovations with actual users to see if they
work even in their programs.  The result is systems like MS Windows or
X Windows, where every program works differently because thought it would
be a Really Neat Idea if his program worked this way.



+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 1 May 92 21:53:13 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
(Rogers) wrote:
>
> the mode-change). Rather than force the user to roll the trackball
> all the way across the screen from the button he's just pressed to
> the map window, my app immediately relocates the cursor to the map
> center, thus minimizing the distance the user has to roll the trackball
> to reach the new center point. Once the new center point has been
> selected, the app relocates the cursor back to its previous position
> in the menu, over the button that was just selected.

Did you test this with actual users?  It might be the case that the time you
save by moving the cursor is outweighed by the time the user spends figuring out
what's going on and locating the cursor.
- -----
Larry Rosenstein
Taligent, Inc.
[e-mail]

+++++++++++++++++++++++++++

Organization: Sophomore, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA
Date: Sat, 2 May 1992 04:17:24 -0400
From: "Jeffrey T. Hutzelman" <[e-mail]>

[e-mail] writes:

> ... my app immediately relocates the cursor to the map
> center, thus minimizing the distance the user has to roll the trackball
> to reach the new center point.  Once the new center point has been
> selected, the app relocates the cursor back to its previous position
> in the menu, over the button that was just selected.

> While this cursor relocation may take "a bit of getting used to," it
> makes the selection of new map centers (a frequent operation) go much
> more smoothly.

Noooooooooooooooooooooooooooooooooooooo!!!!!!!!!!!!!!!!!!!!!!

I have, on occaison, had to work with some specialized quoting software
(in particular, the program that keeps the product database up to date,
but the interface is similar across all of the programs in the package).
Every time I perform certain actions, the program makes assumptions about
where I want the cursor to be, and warps it there.  Two things happen:

1.) 9 times out of 10, I've moved the mouse to the point where I'm going
to click next during the long operation between executing a command and
the cursor warp.  I lose this, and have to do it again.

2.) The pointer on the screen gets out of sync with where the mouse on the
desktop is, and where my mind expects it to be.  It's easy to lift up the
mouse and reposition it, but try to do the same thing with my mind.  It
doesn't work.

I HATE programs that move the cursor "out from under my hand."  It removes
the user's sense of control, and usually makes software harder to use...


Now... in the situation described above, I can understand warping TO the map,
especially if the map and menu windows are far away and/or the trackball is
small and doesn't have much momentum... the ones originally used in video
games had LOTS of momentum, and it was really easy to move very far with
little effort.  However, warping BACK after the command is over only servers
to add more confusion, especially if it happens AFTER a lengthy operation
such as moving and redrawing a map (granted, I don't know how long that's
taking in your application).  If you insist on warping back, do it IMMEDIATELY
after the selection has been made and, if necessary, confirmed.  This both
provides feedback acknowledging the selection, and gives the user time to
react to the new pointer position before they make another selection.

[ Paraphrased, as it scrolled off of my screen... ]
> No practice in desigining good UI's is absolute.

Yes and no.  Specific practices, like "don't warp the cursor" and things
like the arrangement of buttons in a Save/Don't Save/Cancel dialog, are
not absolutes.  General ideas, like make the user feel that they are in
control of the computer instead of the computer being in control of them,
ARE absolute.  Never take control away from the user.

- -- Jeffrey Hutzelman

[e-mail], [e-mail]
JeffreyH11 on America Online

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: 2 May 92 18:28:15 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


       About the only circumstance when the computer must reposition the
pointer is when the screen geometry changes in such a way that the pointer
would be offscreen.  The Radius Pivot comes to mind.

                        John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Jim Cathey)
Date: 4 May 92 20:21:19 GMT
Organization: ISC - Bunker Ramo, Spokane, WA

In article <[e-mail]> [e-mail] (Edward V. Wright) writes:
>So, rather than use scroll bars or a grabber "hand," you chose a
>nonstandard method of scrolling the map.  Then you grab the cursor
>out of the user's hand, forcing him to hunt for it somewhere on the
>map before he can continue.  Still sounds pretty user-nasty to me.
>
>>While this cursor relocation may take "a bit of getting used to," it
>>makes the selection of new map centers (a frequent operation) go much
>>more smoothly.
>
>You can make arguments like that about a lot of operations.  The problem
>is, yours may not be the only program the user uses.  You, as a programmer,
>may be focused on your product, and see it only as "a bit of getting
>used to."  But if the user has a dozen programs, and he has to "get used
>to" the idiosynchronsies of each one (learn them, remember them, and keep
>them straight), he sees it as a pain in the neck.  Worse, many programmers
>never bother testing their innovations with actual users to see if they
>work even in their programs.  The result is systems like MS Windows or
>X Windows, where every program works differently because thought it would
>be a Really Neat Idea if his program worked this way.

Agreed!  Also, consider well what happens if the system has a touch
screen or a tablet running with absolute positioning.  You _can't_
meaningfully move the cursor in such an environment.  It would be
like physically reaching out and yanking a finger to the new
place.  Mouse-warping systems _assume_ that they're running with
a relative-motion device.

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Date: 6 May 92 20:37:51 GMT
Organization: Oberlin College Computer Science


One possible reason that one would want to reposition the cursor on
the screen is for games that involve things moving with momentum.  In
this case, you would want to hide the cursor, but be able to re-center
it so that the motion won't be bounded by the edge of the screen.  How
is this done?

- -matt hall
- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


+++++++++++++++++++++++++++

From: [e-mail] (Hugh Fisher)
Organization: Research School of Chemistry, ANU
Date: Wed, 6 May 92 23:16:35 GMT

  Speaking as someone who has used both Macs and Suns,
  Pointer warping (X Terminology for moving it) is
  A VERY BAD THING. The Sun alert boxes drove me nuts
  until I found out how to turn off the pointer warping.
  What would happen is
      * I click on a button/menu command, say top right of screen.
      * OpenWindows pops up an alert box, usually in the middle.
      * I automatically move the mouse from where I'm looking (top
        right) towards the alert.
      * Since OpenWindows has already moved the cursor, I lose
        sight of it, have to look for it, and mentally send
        death curse #377,498 to the designers.

  I agree that having to move the mouse to an alert is a hassle,
  especially on a large screen. What ought to happen is that the
  alert pops up under the current cursor position, if possible
  with the most likely button choice under the cursor. No
  movement required, no break in focus, almost guaranteed to
  attract attention. Major drawback: requires programmer to do
  some work instead of the user :-)

+++++++++++++++++++++++++++

From: [e-mail] (Joe Francis)
Date: 7 May 92 03:10:07 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Hugh Fisher) writes:

>   I agree that having to move the mouse to an alert is a hassle,
>   especially on a large screen. What ought to happen is that the
>   alert pops up under the current cursor position, if possible
>   with the most likely button choice under the cursor.

I agree whole-heartedly with the first part of your solution.  I would
only add that it might be best if no button is directly under the
cursor.  I know that I will sometimes "over-anticipate" software and
make a mouse click that I wouldn't have made if I had read the alert.
Having to move the mouse a little gives me a chance to notice that the
name on the button was "cancel" instead of the expected "save".

+++++++++++++++++++++++++++

From: [e-mail]
Date: 7 May 92 03:29:34 CST
Organization: University of Missouri-Kansas City

In article <[e-mail]>, [e-mail] (Hugh Fisher) writes:
>   Pointer warping (X Terminology for moving it) is
>   A VERY BAD THING.
yes.

>   I agree that having to move the mouse to an alert is a hassle,
>   especially on a large screen. What ought to happen is that the
>   alert pops up under the current cursor position, if possible
>   with the most likely button choice under the cursor. No
>   movement required, no break in focus, almost guaranteed to
>   attract attention. Major drawback: requires programmer to do
>   some work instead of the user :-)

Problem is not extra work on the programers part, but that suppose
the default button is on the lower right corner of the dialog box,
and my cursor was in the upper left corner of the screen, then when
the dialog box pops up I'll get this situation:


     +------------+
     | Dialog Box |
     |           +----------------------+
     +-----------|+                     |
                 |    Physical Screen   |
                 |                      |
                 +----------------------+

Can make it mighty tough to read that alert :-)

Jonathan/[e-mail]



+++++++++++++++++++++++++++

From: [e-mail] (Richard Chandler)
Date: 5 May 92 19:20:28 GMT
Organization: InterCon Systems Corporation


  If I may suggest a better interface for our map-user:
User clicks on the map at the point he wishes to have in the center (If
clicking has different purposes, give a palette of different cursors.) then
mark that point on the map.  Then the user can click on the centering button,
or not, perhaps mark a different poin on the map if they change their mind.
Actually, if moving the map is relatively fast, and you present a palette of
cursors, the re-centering can occur immediately after a click.
  Some may say "What is the difference between clicking on a button and
clicking on a palette?"  To understand this is to understand the Mac
interface.  Clicking on a palette does not necessarily commit the user to an
action.  He can still click on another part of the pallette, or on a Menu.

  Of course, anyone who read the post closely would realize that he is not
programming for the Mac.  So the entire arguement is moot.

- --
Praying for the day when "Sex Scandal" is an oxymoron.
"Ride a motorcycle.  Save Gas, Oil, Rubber, Steel, Aluminum, Parking Spaces,
 The Environment, and Money.  Plus, you get to wear all the leather you want!"
 Rich Chandler, DoD #296

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 7 May 1992 14:02:29 GMT

[e-mail] writes:
>[e-mail] (Hugh Fisher) writes:
>>   Pointer warping (X Terminology for moving it) is
>>   A VERY BAD THING.
>yes.
yes, yes.

>>   What ought to happen is that the
>>   alert pops up under the current cursor position
>>   Major drawback: requires programmer to do
>>   some work instead of the user :-)
>
>Problem is not extra work on the programers part, but that suppose
>the default button is on the lower right corner of the dialog box,
>and my cursor was in the upper left corner of the screen, then when
>the dialog box pops up I'll get this situation:
>
>
>     +------------+
>     | Dialog Box |
>     |           +----------------------+
>     +-----------|+                     |
>                 |    Physical Screen   |
>                 |                      |
>                 +----------------------+

That's where the extra work for the programmer comes in.  You have to
center the alert on the cursor.  (That'd probably be best.)  Then check
to make sure the whole alert's visible on one screen.  If not, move it
to the most likely screen.  Move it in from the edge by a certain
margin.  Don't forget the menubar!  And make sure that, in its final
position, no dangerous buttons--indeed, probably no buttons at all--are
underneath the cursor.  In the event that "Initialize" happens to end up
right under the hot spot, re-repositioning the dialog is left as an
exercise for the reader.  :-)

If your screen is so large that you can't find your cursor, try using
one of those double-size cursors.  Most large screens come with software
to do this, and I think I remember some PD init...?
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Civil Rights:  1964 - 1992.  R.I.P.

+++++++++++++++++++++++++++

From: [e-mail] (Mel Walker)
Organization: Novell, Inc. - Walnut Creek
Date: Thu, 7 May 1992 15:37:26 GMT

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>If your screen is so large that you can't find your cursor, try using
>one of those double-size cursors.  Most large screens come with software
>to do this, and I think I remember some PD init...?

I have been known to use a little INIT that shows a pair of eyeballs in the
menubar that follow the cursor. It makes it handy to have something always
staring at the cursor, even if I'm not.
- --
+------------------------------+---------------------------------------------+
+ Mel Walker                   | ******** Dave Barry for President ********  +
+ [e-mail] |  "A clever slogan should be written here"   +
+------------------------------+---------------------------------------------+

+++++++++++++++++++++++++++

From: [e-mail]
Date: 7 May 92 22:09:40 GMT
Organization: Oxford University VAXcluster

In article <[e-mail]>, [e-mail] (Hugh Fisher) writes:
>   I agree that having to move the mouse to an alert is a hassle,
>   especially on a large screen. What ought to happen is that the
>   alert pops up under the current cursor position, if possible
>   with the most likely button choice under the cursor. No
>   movement required, no break in focus, almost guaranteed to
>   attract attention. Major drawback: requires programmer to do
>   some work instead of the user :-)
Good suggestion . . . one problem I can see though, I'm just clicking on
something when up pops an alert under the cursor and I click on that instead of
what I wanted to click on. How about the alert popping up just a little away
from the cursor.

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 8 May 92 15:27:05 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:

>That's where the extra work for the programmer comes in.  You have to
>center the alert on the cursor.  (That'd probably be best.)  Then check
>to make sure the whole alert's visible on one screen.  If not, move it
>to the most likely screen.  Move it in from the edge by a certain
>margin.  Don't forget the menubar!  And make sure that, in its final
>position, no dangerous buttons--indeed, probably no buttons at all--are
>underneath the cursor.  In the event that "Initialize" happens to end up
>right under the hot spot, re-repositioning the dialog is left as an
>exercise for the reader.  :-)



Of course all this has been done already. I think Pete Helm has an init
that does this alert/dialog repositioning. I think its called Front and Center.
In any case, its on the Developer's CD.





Matt





- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Rick Holzgrafe)
Date: 8 May 92 21:35:19 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
writes:
>
> In article <[e-mail]>, [e-mail]
(Hugh Fisher) writes:
> >   I agree that having to move the mouse to an alert is a hassle,
> >   especially on a large screen. What ought to happen is that the
> >   alert pops up under the current cursor position
> [...]
> How about the alert popping up just a little away
> from the cursor.

I'd like to see some comprehensive user testing on this notion before everybody
jumps on the bandwagon. I have a pretty slapdash mouse style, and I often wave
the cursor away from the last thing I clicked in a wide, grand gesture. (I don't
like the cursor in the way when I'm reading things.) If the alerts chase the
cursor, they'll be popping up all over the place, everywhere except where I
expect them: centered on either the window or the monitor.

Yes, I have a large monitor (two, in fact); yes, I hate dragging the mouse all
over it to get where I want to go. But I hate surprises even more.

- -- Rick Holzgrafe, a member of the Taligentsia
   [e-mail]
   [e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Hugh Fisher)
Organization: Research School of Chemistry, ANU
Date: Sun, 10 May 92 23:24:40 GMT


  A clarification of how this user would like popup
  alerts and dialogs to work:

  For alerts generated by the currently active
  application, I would like it to appear where I
  am currently looking.

  Ideally this would be with an eye tracker: if I'm
  looking at the screen, pop up there; if I'm staring
  into space, beep if it is really urgent, otherwise
  wait until I return.

  Without an eye tracker, the mouse cursor seems like
  a reasonable guess. As Rick Holzgrafe points out,
  this isn't true when you are typing. So, pop up the
  alert
     * under or near to the mouse cursor if the mouse
       has moved in the past few seconds.

     * under/near the text cursor, active cell, or
       whatever depending on application otherwise.

  Several people have pointed out that it is dangerous
  to pop up with a button directly under the mouse, so
  arrange not to do so as well.

  This is the result of non-comprehensive user testing
  on a sample of one. Thank you Rick for reminding us
  that user testing is more important than imagination.

+++++++++++++++++++++++++++

From: [e-mail] (K. Fischer)
Date: 11 May 92 15:14:46 GMT
Organization: LLNL

Why couldn't alert/dialog box placement be a user tailorable option,
like cursor speed and the number of times a menu item blinks when you
click on it?  Have a control panel which has the most popular options
listed
and let each user pick the one most applicable to their tastes and
needs.
- -- How about:
    1) a toggle button if the user likes mouse warping (default  = no
warp)
    2) a toggle button if the user likes the default button centered
        under the mouse (default = cursor not over button any button)
    3) a radio box with options for where the user would like
        alerts and dialogs to show up:
              a) always centered on the current screen
              b) always *appropriately* placed near the cursor
              c) left to the descression (sp?) of the current
application
              d) ... ??? any one else have an idea ??? ...

Hmmm, that's all I can think of off the top of my head.  Maybe we need
a standard dialog/alert placement call that would then display the box
correctly in a UI conforment maner based on user selectable criteria?

- --
Kathleen Fischer
[e-mail]

DISCLAIMER: Statements expressed here are mine, Mine, MINE!!!

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Tue, 12 May 1992 01:25:46 GMT

In article <[e-mail]>, [e-mail] (K. Fischer) writes:
>
> Why couldn't alert/dialog box placement be a user tailorable option,
> like cursor speed and the number of times a menu item blinks when you
> click on it?  Have a control panel which has the most popular options
> listed and let each user pick the one most applicable to their tastes and
> needs.
> -- How about:
>     1) a toggle button if the user likes mouse warping (default  = no
>        warp)
>     2) a toggle button if the user likes the default button centered
>         under the mouse (default = cursor not over button any button)
>     3) a radio box with options for where the user would like
>         alerts and dialogs to show up:
>               a) always centered on the current screen
>               b) always *appropriately* placed near the cursor
>               c) left to the descression (sp?) of the current
>                  application
>               d) ... ??? any one else have an idea ??? ...

User interface customisation is a wonderful thing but can you have too much
of it?  The answer, IMHO, is YES!!!  Too much customisation of the user
interface means that when some naive user moves from Mac A to Mac B they
have absolutely no idea what's going on.  Until the Mac support multiple
users (in the sense that when one user starts the Mac is reconfigured
exactly how *they* left it) this will remain a problem.

I recognise that's not going to stop the hackers out there putting together
a control panel that does the above but I maintain that Apple is right in
not putting this sort of thing into the system.  Besides Sys 7 is big
enough already (-:

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Who's use of a Dvorak keyboard confuses *everyone* who tries to
       type over his shoulder (-:


+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 12 May 92 02:20:10 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Matt Mora) writes:

> Of course all this has been done already. I think Pete Helm has an init
> that does this alert/dialog repositioning. I think its called Front and Center.
> In any case, its on the Developer's CD.

Yeah, and on my machine (Mac+ 4/105 w/Sys. 7) it drew alerts that
started at the mouse position and extended past the bottom and right of
my paltry 512*342 pixel screen. It also froze the computer while doing
all this.

No longer running Front And Center,
Jeremiah

+++++++++++++++++++++++++++

From: [e-mail] (Rick Holzgrafe)
Date: 14 May 92 22:45:07 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
(Hugh Fisher) writes:
>   Without an eye tracker, the mouse cursor seems like
>   a reasonable guess. As Rick Holzgrafe points out,
>   this isn't true when you are typing. So, pop up the
>   alert
>      * under or near to the mouse cursor if the mouse
>        has moved in the past few seconds.
>
>      * under/near the text cursor, active cell, or
>        whatever depending on application otherwise.

Still wouldn't satisfy me - as I said, I often click a button
and reflexively sweep the mouse out of the way; if the alert
chases the mouse, I'll be bothered.

>   This is the result of non-comprehensive user testing
>   on a sample of one. Thank you Rick for reminding us
>   that user testing is more important than imagination.

You're welcome, but I'm all in favor of imagination!
You need *both* imagination and testing to create a
good UI. Neither is "more important."

(I'm a preachy convert about this. I have a product
in late beta test that didn't get user testing early
enough. It's still a good product (IMHO!) but it
would have been better if I'd tested earlier. My
users have made many great suggestions, but some of
them now have to wait for a version 2.0.)

- -- Rick Holzgrafe, a member of the Taligentsia
   [e-mail]
   [e-mail]

---------------------------

From: [e-mail] (Matthew Hall)
Subject: How to get 360 dpi on stylewriter.
Organization: Oberlin College Computer Science
Date: Fri, 15 May 1992 03:19:58 GMT

Hello-
    Being rather impressed with the resolution of my stylewriter,
I decided that I wanted to be able to draw full resolution pictures of
the mandelbrot set. (Yes, it is an overused graphic, but I'm a math
major and allowed to do such things).
    I started off on my quest with IMII and the tech notes stack.
I opened the printer driver, opened the document, and opened a page.
Then I looked at the resulting data structures.  In the Info field, I
had hres and vres at 360dpi.  The rpage rect looked about right(around
2000 wide and 3500 tall).  However, the rPaper rectangle was set to
the 72 dpi dimensions.  Furthermore, the portrect in my Printing port
was in the 72dpi dimensions.
So I printed a 500x500 circle.  It was an absolutely beautiful circle,
perfectly round at 360 dpi quality.  However, if the coordinates were
in 360dpi mode, it would have been less than 2 inches in diameter.  As
it was, it was the full page wide, in 72dpi coordinates.
    So what's going on?  IMII says that the rPaper rectangle
should contain the rpage rectangle.  I want to access each pixel
individually, but I can't unless my portrect matches rPage. Can I
address each pixel individually on the stylewriter (with moveto,
line(0,0) calls)?  Please help.

thank you
- -matt hall

- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Sat, 16 May 92 18:11:52 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (Matthew Hall) writes:
>Hello-
>    Being rather impressed with the resolution of my stylewriter,
>I decided that I wanted to be able to draw full resolution pictures of
>the mandelbrot set. (Yes, it is an overused graphic, but I'm a math
>major and allowed to do such things).

Use PrGeneral's "SetResl" selector-- check the tech notes and Inside
Mac V.

- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

---------------------------

End of C.S.M.P. Digest
**********************